協働通信技術

专利摘要:
ソースデバイスとデスティネーションデバイスとの間の通信に関する技術を開示する。当該通信においては、複数の協働デバイスが、ソースデバイスが送った送信を再送（例えば、同時に再送）するとしてよい。このため、ソースデバイスからデスティネーションデバイスへと送信を配信する際に、２以上の「ホップ」が利用されるとしてよい（例えば、第１の「ホップ」は最初の送信を含み、第２の「ホップ」は２以上の中継送信を含む）。Ａ
公开号:JP2011514109A
申请号:JP2010549947
申请日:2009-04-14
公开日:2011-04-28
发明作者:オイマン、オズガー；シディール、ジャロスロー
申请人:インテル・コーポレーション；
IPC主号:H04L1-16

专利说明:

[0001] 無線データ通信ネットワークは、低速フェージングの影響を受けることが多い。低速フェージングとは、信号が伝搬する環境の変化がデータ通信速度に比べて低速な場合に発生する現象である。低速フェージングは、通信チャネルのコヒーレンス時間が複数のフレーム期間よりも長い場合に発生することがある。]
[0002] 低速フェージングは、バーストエラーといった通信障害の原因となる可能性がある。このようなバーストがあると、データ通信性能が大幅に劣化し、送信されたデータのデコードの信頼性に悪影響を及ぼす可能性がある。無線ネットワークにおける低速フェージングを軽減する方法の１つに、複数の端末がアンテナ等のリソースを共有するという協働的ダイバーシティ技術を利用する方法がある。このような技術を利用すると、分散型の送信および信号処理によって、仮想アレイ（つまり、仮想的な多入力多出力（ＭＩＭＯ）システム）が形成される。この結果、空間ダイバーシティおよび分散型のアレイゲインが実現され得る。]
[0003] 通信システムである程度の遅延が許容され得るとすると、自動再送制御（ＡＲＱ）プロトコルを利用することによってエラーを含むデータを再送することができる。このようなプロトコルによると、受信側デバイスは、エラーがあるか否かについて（例えば、巡回冗長検査（ＣＲＣ）を用いて）フレームを調べる。受信したフレームでエラーが検出されない場合、受信側は、送信側デバイスに対して、送信が成功した旨を知らせる応答（ＡＣＫ）を送信する。しかし、エラーが検出されれば、再送を要求する否定応答（ＮＡＣＫ）を送信側デバイスに送信する。例えば、フレームが途中で失われて受信側が受信自体しなかった場合など、ＮＡＣＫが送信されない場合もある。また、送信側デバイスは、制限時間内にＡＣＫを受信しないことによって、ＮＡＣＫと解釈する場合もある。送信側デバイスは、ＮＡＣＫを受信すると、フレームを再送する。この処理は、ＡＣＫを受信するまで、または、再送制限回数に到達するまで、行われるとしてよい。]
[0004] ＡＲＱプロトコルに加えて、ハイブリッドＡＲＱ（ＨＡＲＱ）アルゴリズムを利用するとしてもよい。ＨＡＲＱプロトコルの動作原理は基本的にＡＲＱプロトコルと同様であるが、信頼性およびスループットを改善するべく、エラーの検出および訂正を組み合わせて、例えば、エラー訂正コードによってデータビットおよびＣＲＣビットをさらに保護して、送信成功率を高くする。さらに、ＨＡＲＱプロトコルでは、チェイス・コンバイニング（Ｃｈａｓｅ Ｃｏｍｂｉｎｉｎｇ）、インクレメンタル・リダンダンシ（Ｉｎｃｒｅｍｅｎｔａｌ Ｒｅｄｕｎｄａｎｃｙ）、または、コード・コンバイニング（Ｃｏｄｅ Ｃｏｍｂｉｎｉｎｇ）等の技術を利用して、以前に観察されたエラーを含むパケットと、再送されるパケットとを組み合わせるとしてよい。]
[0005] ある状況下では、既存のＡＲＱプロトコルおよびＨＡＲＱプロトコルは、通信リンクの信頼性を高める上では十分な役割を果たさない。例えば、ディープ・フェージングが発生すると、最初の送信時およびその後の再送時の両方でチャネルの状態が悪い可能性があるので、既存のＡＲＱプロトコルおよびＨＡＲＱプロトコルでは通信リンクの品質を改善することができない。このため、平均再送回数が非常に多くなると共に、スループットが非常に低くなってしまう。]
図面の簡単な説明

[0006] 通信環境を示す図である。
通信環境を示す図である。
通信環境を示す図である。
通信環境を示す図である。
ロジックフローの一例を示す図である。
ロジックフローの一例を示す図である。
ロジックフローの一例を示す図である。
デバイスの実施例を示す図である。
ネットワークフレームフォーマットを示す図である。
通信の一例を示す図である。
通信の一例を示す図である。
通信の一例を示す図である。
通信の一例を示す図である。]
実施例

[0007] さまざまな実施形態は、ソースデバイスとデスティネーションデバイスとの間での通信に関連するとしてよい。このような通信では、ソースデバイスが送る送信を再送または中継する協働デバイスが複数利用され得る。例えば、複数の協働デバイスは同時に再送するとしてよい。このように、ソースデバイスからデスティネーションデバイスへの送信の配信には、２以上の「ホップ」（例えば、第１の「ホップ」は最初の送信を含み、第２の「ホップ」が２以上の中継再送信を含む）を利用するとしてよい。]
[0008] このように、実施形態では、無線リンクが多数あることを利用するとしてよく、ソースデバイスおよび協働デバイス（デスティネーションデバイスに対する接続の品質について、高いものと低いものがある）を互いに協働させることによって、空間ダイバーシティおよびアレイゲインを実現するとしてよい。この結果、デスティネーションデバイスがソースデバイスから受信する複数の送信は、最初の送信がそれぞれ独自にフェージングしたもの（最初の送信の再送）であるとしてよい。このようにすることで、デスティネーションデバイスで確実にデコードできる可能性が高くなる。この結果、デコードを成功させるために必要な予想再送回数が低減されるという効果が得られる。]
[0009] また、実施形態によっては、ソースデバイスとデスティネーションデバイスとの間には直接的なリンクが全く存在しないか、または、データの送信には（例えば、選択されて）利用されない場合がある。このような場合には、ソースデバイスとデスティネーションデバイスとの間の通信には、ソースデバイスからの送信を受信して、当該ソースデバイスからの送信を中継する協働デバイスが複数利用され得る。複数の協働デバイスは、例えば、同時にソースデバイスからの送信を再送する。]
[0010] さらに、ＨＡＲＱ処理は、例えば、ソースデバイスとデスティネーションデバイスとの間に直接的なリンクが存在しない場合に、リンク毎、または、ホップ毎に実行されるとしてよい。このように、各ホップについて、送信および再送は、受信側デバイスが受信に成功するまで、継続して実行されるとしてよい。]
[0011] ＜Ｉ．動作環境＞
図１Ａから図１Ｄは、複数のデバイス間で通信が実行される環境の一例を示す図である。具体的には、当該環境は、ソースデバイス１０２と、デスティネーションデバイス１０４と、複数の協働デバイス１０６、１０８、１１０、および１１２を備える。これらのデバイス同士は、任意の通信プロトコルに従って、送信をやり取りするとしてよい。さらに、送信について、任意の送信技術および／またはデコード方式（例えば、エラー検出／訂正コーディングまたはネットワークコーディング）を採用するとしてよい。] 図１Ａ 図１Ｄ
[0012] 図１Ａから図１Ｄに示す協働デバイスは４つ（１０６、１０８、１１０、および１１２）であるが、環境が備える協働デバイスの数は任意であってよい。また、実施形態によっては、任意の数のソースデバイスおよび／またはデスティネーションデバイスを任意の数の協働デバイスと対応付けるとしてよい。] 図１Ａ 図１Ｄ
[0013] 実施形態によっては、ソースデバイス１０２とデスティネーションデバイス１０４との間の通信を協働デバイスが支援するとしてよい。例えば、図１Ａおよび図１Ｂでは、中継支援方式に応じた通信の一例を示す。図１Ａに示すように、ソースデバイス１０２は、デスティネーションデバイス１０４に送信１２０を送る。不図示であるが、協働デバイス１０８および１１２も送信１２０を受信する。] 図１Ａ 図１Ｂ
[0014] 本例では、デスティネーションデバイス１０４は、送信１２０をデコードすることができない。このため、図１Ａでは、協働デバイス１０８および１１２が、再送１２２および１２４（つまり、送信１２０の再送）をデスティネーションデバイス１０４に送っている様子を示している。しかし、実施形態によっては、デスティネーションデバイス１０４が最初の送信１２０のデコードに失敗すると、任意の数の協働デバイスが送信１２０の協働再送信を実行するとしてよい。] 図１Ａ
[0015] 実施形態によっては、ソースデバイス１０２も協働デバイスとして動作するとしてよい。このため、図１Ｂでは、ソースデバイス１０２がデスティネーションデバイス１０４に送信１２６を送っている。図１Ｂではさらに、ソースデバイス１０２がデスティネーションデバイス１０４に対して再送１３０を送っている様子と、協働デバイス１０８が再送１２８をデスティネーションデバイス１０４に送っている様子を示している。これらの再送は、送信１２６の再送である。また、これらの再送は、協働技術に基づき同時に実行されるとしてよい。] 図１Ｂ
[0016] 図１Ａおよび図１Ｂにおいて、このような再送が発生するのは、デスティネーションデバイス１０４がソースデバイス１０２から最初の送信（例えば、送信１２０または送信１２６）を受信しない（または、最初の送信のデコードが不成功に終わる）ためであるとしてよい。これは、例えば、ＮＡＣＫメッセージング機能によって判断するとしてよい。] 図１Ａ 図１Ｂ
[0017] 図１Ｃおよび図１Ｄは、ホップ単位方式に応じた通信の一例を示す。当該方式によると、ソースデバイス１０２とデスティネーションデバイス１０４との間では、直接的なリンクを利用しない。このような事態は、両デバイス間のリンクが存在しないか、品質が低いために発生し得る。したがって、この方式が利用されるのは、データ送信がデスティネーションデバイス１０４に到達できない（または、到達する可能性がない）場合であるとしてよい。しかし、当該方式が利用されるのは、このような状況に限定されない。] 図１Ｃ 図１Ｄ
[0018] 図１Ｃに示すように、ソースデバイス１０２は送信１３２を送る。この送信は、協働デバイス１０８および１１２によって受信される。協働デバイス１０８および１１２は、送信１３２を確実にデコードする。そして、協働デバイスは、デスティネーションデバイス１０４に対して、再送１３４および１３６（つまり、送信１３２の中継後バージョン）を送る。これらの再送は、送信１３２と同じ内容の情報を含んでいる。協働デバイス１０８および１１２は、必要であれば、デスティネーションデバイス１０４が受信に成功するまで、再送１３４および１３６の再送を協働技術に基づいて実行するとしてよい。] 図１Ｃ
[0019] 上述したように、ソースデバイス１０２はさらに、協働デバイスとして動作するとしてもよい。したがって、図１Ｄでは、ソースデバイス１０２が送信１３８を送っている。送信１３８は、協働デバイス１０８によって確実にデコードされる。そして、ソースデバイス１０２は、デスティネーションデバイス１０４に対して再送１４２を送り、協働デバイス１０８はデスティネーションデバイス１０４に対して再送１４０を送る。これらの再送（送信１３８の中継後送信）は、送信１３８と同じ内容の情報を含んでいる。ソースデバイス１０２および協働デバイス１０８は、必要であれば、デスティネーションデバイス１０４が受信に成功するまで、再送１４０および１４２の再送を協働技術に基づいて実行するとしてよい。] 図１Ｄ
[0020] ソースデバイス１０２および／またはデスティネーションデバイス１０４は、図１Ａから図１Ｄに示した再送の実行および特性を決定するとしてよい。この処理には、当該再送を送る協働デバイス群を選択することと、当該再送に利用する送信技術（例えば、分散型時空間コーディング、分散型ビームフォーミング等）を選択することとが含まれるとしてよい。また、ソースデバイス１０２および／またはデスティネーションデバイス１０４は、これらの協働デバイスと通信して、再送を円滑化するとしてよい。] 図１Ａ 図１Ｄ
[0021] （図１Ａから図１Ｄに示すように）２以上の協働デバイスを利用することによって、ダイバーシティが改善されるという効果が得られる。この結果、送信を送る際および再び送る際に、複数の異なる経路にわたって適切にコーディングした信号を送ることによって、信頼性が改善され得る。また、複数の協働デバイスを利用することによって、「第１のホップ」による送信のデコードが少なくとも１つの協働デバイスで成功する確率が高くなる。このため、ソースデバイスが第１のホップの送信を（デコードが不成功に終わったために）再度送らなければならない可能性が低くなるとしてよい。] 図１Ａ 図１Ｄ
[0022] 実施形態をさらに、以下の図面および事例を参照しつつ説明する。図面の中には、ロジックフローを含むものもある。本明細書で提示する図面は特定のロジックフローを含むが、そのようなロジックフローは、本明細書に記載される一般化された機能がどのように実装され得るかの一例を示すに過ぎないものと理解されたい。また、提示するロジックフローは、明示されていない限り、必ずしも提示した順序で実行する必要はない。また、提示するロジックフローは、ハードウェア素子、プロセッサが実行するソフトウェア素子、または、それらの任意の組み合わせによって実装されるとしてよい。実施形態はこの点に限定されない。]
[0023] ＜ＩＩ．ロジックフローの例＞
図２Ａおよび図２Ｂは、ソースデバイスからデスティネーションデバイスへと通信を配信する際に協働デバイスを利用するロジックフローの例を示す図の例である。具体的に説明すると、図２Ａに示すフローでは、中継支援方式（図１Ａおよび図１Ｂの例と同様）に係る例を示している。一方、図２Ｂに示す流れ図では、ホップ単位方式（図１Ｃおよび図１Ｄの例と同様）に係る例を示している。] 図１Ａ 図１Ｂ 図１Ｃ 図１Ｄ 図２Ａ 図２Ｂ
[0024] これらのフローは、ソースデバイス、複数の協働デバイス、デスティネーションデバイスに基づいて説明する。上述したように、協働デバイス群にはソースデバイスが含まれ得る。図２Ａおよび図２Ｂはそれぞれ特定の順序で図示されているが、その他の順序で実行されるとしてもよい。また、図示されている動作は、並列に、および／または、逐次実行されるとしてよい。] 図２Ａ 図２Ｂ
[0025] 図２Ａおよび図２Ｂに示した方式はそれぞれ、異なる状況で採用されるとしてよい。例えば、図２Ａに示す方式は、ソースデバイスとデスティネーションデバイスとの間に直接的な通信リンクが存在する場合に採用されるとしてよい。しかし、図２Ｂに示す方式は、ソースデバイスとデスティネーションデバイスとの間に直接的な通信リンクが存在しない場合（または、そのような直接的な通信リンクが弱い場合）に採用されるとしてよい。] 図２Ａ 図２Ｂ
[0026] 図２Ａは、中継支援方式が採用されるロジックフロー２００を示す図である。この方式は、本明細書において、改良された協働的中継支援型ハイブリッドＡＲＱ（ＨＡＲＱ）アルゴリズムとも呼ぶ。] 図２Ａ
[0027] 図２Ａに示すフローのブロック２０２では、ソースデバイスがデスティネーションデバイスに対して送信を送る。この際、デスティネーションデバイスは、この送信について待機（「監視」）状態であるとしてよい。さらに、１以上の協働デバイスが同じ送信について待機状態にあるとしてよい。また、デスティネーションデバイスおよび１以上の協働デバイスは、ソースデバイスが送った送信のデコードを試みる。デコードを試みた結果に応じて、デスティネーションデバイスおよび協働デバイスは、応答（例えば、ＡＣＫ／ＮＡＣＫ）メッセージを送信（例えば、ブロードキャスト）するとしてよい。] 図２Ａ
[0028] したがって、デスティネーションデバイスおよび１以上の協働デバイスから応答（ＡＣＫまたはＮＡＣＫ）が送られてくるか否かを検出する。さらに、所定期間が経過しても返答がないことを以て、ＮＡＣＫと解釈するとしてもよい。]
[0029] ブロック２０４において、デスティネーションデバイスがＡＣＫを送ったか否かを判断する。送っていれば、ブロック２０６に進む。送っていなければ、ブロック２０８に進む。]
[0030] ブロック２０６では、デスティネーションデバイスが送信の受信に成功したと結論付けられる。このため、実施形態によっては、（採用されている通信プロトコル、送信スケジュール等に従って）ソースデバイスがデスティネーションデバイスに対して（あるとすれば）さらに送信を送るとしてもよい。]
[0031] しかし、ブロック２０８では、デスティネーションデバイスおよび全ての協働デバイスがＮＡＣＫを送ったか否か判断される。デスティネーションデバイスおよび全ての協働デバイスがＮＡＣＫを送っていれば、ブロック２０２に戻り、ソースデバイスは送信を再度送る。]
[0032] しかし、デスティネーションデバイスおよび全ての協働デバイスがＮＡＣＫを送っていなければ、ブロック２１０において、デスティネーションデバイスがＮＡＣＫを送って、少なくとも１つの協働デバイスがＡＣＫを送ったか否かを判断する。そうであれば、ブロック２１３に進む。]
[0033] ブロック２１３において、協働デバイス群は、ブロック２０２で送られた送信を再送する。この協働デバイス群を形成することは、ＡＣＫメッセージを送った協働デバイスの中から選択することを含む（ソースデバイスがこの協働デバイス群に含まれるとしてもよい）。協働デバイス群が複数のデバイスを含む場合、再送は、分散型送信技術を利用して行うとしてよい。そのような送信技術の一例を挙げると、（これらに限定されないが）、仮想多入力多出力（ＭＩＭＯ）技術、分散型時空間コーディング技術、および／または、分散型ビームフォーミング技術が含まれる。しかし、実施形態は、このような例に限定されるものではない。実施形態によっては、デスティネーションデバイスは、対応して受信方式を適応させることができるように、特定の再送技術について通知される。]
[0034] 再送の後、デスティネーションデバイスから返答の送信があるか否か検出される。上述したように、この返答の送信は、ＡＣＫまたはＮＡＣＫであるとしてよい。]
[0035] ブロック２１４において、デスティネーションデバイスがＮＡＣＫを送ったか否か判断される。ＮＡＣＫを送っていれば、ブロック２１３に戻り、再送を再度送る。このように、協働デバイスは、デスティネーションデバイスがパケットを正しくデコードするまで、または、設定されている最高再送回数に到達するまで、送信を再送し続けるとしてよい。実施形態によっては、協働デバイス群は、再送を実行する度に変更するとしてもよい。]
[0036] ブロック２１６に示すように、デスティネーションデバイスがＡＣＫを送ると、ブロック２１８に進む。このブロックにおいて、デスティネーションデバイスによる再送の受信が成功したと判断される。このため、（採用されている通信プロトコル、送信スケジュール等に従って）ソースデバイスがデスティネーションデバイスに対して（あるとすれば）さらに送信を送るとしてもよい。]
[0037] 図２Ｂは、ホップ単位方式が採用されるロジックフロー２５０を示す図である。この方式は、本明細書において、改良された協働的ホップ単位ハイブリッドＡＲＱ（ＨＡＲＱ）アルゴリズムとも呼ぶ。] 図２Ｂ
[0038] 図２Ｂに示すフローのブロック２５２では、ソースデバイスが送信を送る。この際、１以上の協働デバイスがこの送信について待機状態であるとしてよい。また、１以上の協働デバイスは、ソースデバイスが送る送信のデコードを試みる。デコードを試みた結果に応じて、協働デバイスは、応答（例えば、ＡＣＫ／ＮＡＣＫ）メッセージを送信（例えば、ブロードキャスト）するとしてよい。] 図２Ｂ
[0039] この後、１以上の協働デバイスからの返答の送信が送られてくるか否かを検出する。上述したように、この返答は、ＡＣＫおよびＮＡＣＫであるとしてよい。さらに、所定期間が経過しても返答がないことを以て、ＮＡＣＫと解釈するとしてもよい。]
[0040] ブロック２５４において、全ての協働デバイスがＮＡＣＫを送ったか否か判断する。全ての協働デバイスがＮＡＣＫを送っていれば、ブロック２５２に戻り、ソースデバイスは再度送信を送る。しかし、全ての協働デバイスがＮＡＣＫを送っていなければ、ブロック２５７に進む。]
[0041] ブロック２５７において、協働デバイス群が、ブロック２５２で送られた送信を再送（例えば、同時に再送）する。この協働デバイス群を形成することは、ＡＣＫメッセージを送った協働デバイスの中から選択することを含む（ソースデバイスがこの協働デバイス群に含まれるとしてもよい）。協働デバイス群が複数のデバイスを含む場合、再送は、分散型送信技術を利用して行うとしてよい。上述したように、そのような送信技術の一例を挙げると、（これらに限定されないが）、仮想ＭＩＭＯ技術、分散型時空間コーディング技術、および／または、分散型ビームフォーミング技術が含まれる。しかし、実施形態は、このような例に限定されるものではない。実施形態によっては、デスティネーションデバイスは、対応して受信方式を適応させることができるように、特定の再送技術について通知される。]
[0042] この後、デスティネーションデバイスから返答の送信があるか否か検出される。上述したように、この返答の送信は、ＡＣＫまたはＮＡＣＫであるとしてよい。]
[0043] ブロック２５８において、デスティネーションデバイスがＮＡＣＫを送ったか否か判断される。ＮＡＣＫを送っていれば、ブロック２５７に戻り、再送を再度送る。このように、協働デバイス群は、デスティネーションデバイスがパケットを正しくデコードするまで、または、設定されている最高再送回数に到達するまで、送信を再送し続けるとしてよい。実施形態によっては、協働デバイス群は、再送を実行する度に変更するとしてもよい。]
[0044] しかし、ブロック２６０は、デスティネーションデバイスがＡＣＫを送れば、ブロック２６２に進むことを示している。このブロックでは、デスティネーションデバイスによる再送の受信が成功したと判断される。このため、ソースデバイス２２０は、（採用されている通信プロトコル、送信スケジュール等に従って）デスティネーションデバイスに対して指定されている送信を（あるとすれば）さらに送るとしてもよい。]
[0045] 上述した技術は、さまざまな種類の通信ネットワークで採用されるとしてよい。ネットワークの例を挙げると、（これらに限定されないが）米国電気電子学会（ＩＥＥＥ）８０２．１６に準拠したネットワーク（例えば、ＷｉＭＡＸ（ワールドワイド・インターオペラビリティ・フォー・マイクロウェーブ・アクセス）ネットワークおよびＷｉＭＡＸ ＩＩネットワーク）等がある。]
[0046] このようなネットワークでは、上述した技術をアップリンク送信およびダウンリンク送信の両方に用いるとしてよい。ダウンリンク送信の場合、ソースデバイスには基地局が含まれるとしてよく、協働デバイスには中継局が含まれるとしてよく、デスティネーションデバイスには移動局が含まれるとしてよい。アップリンク送信の場合、ソースデバイスには移動局が含まれるとしてよく、協働デバイスには中継局が含まれるとしてよく、デスティネーションデバイスには基地局が含まれるとしてよい。しかし、実施形態はこれらの例に限定されるものではない。]
[0047] 本明細書に記載するように、２ホップ通信は、さまざまな点において、ソースデバイスおよび／またはデスティネーションデバイスといったデバイスの指揮下にあるとしてよい。例えば、基地局が２ホップ通信を特定の点に関して指揮する例を以下に記載する。このような例では、基地局は、ダウンリンク通信についてはソースデバイスとして動作し、アップリンク通信ではデスティネーションデバイスとして動作するとしてよい。]
[0048] 図３は、あるデバイスが２ホップ通信を指揮する場合のロジックフロー３００を示す図である。このデバイスは、ソースデバイスであってもよいし、または、デスティネーションデバイスであってもよい。例えば、このデバイスは基地局であってよい。しかし、その他のデバイスが同図に図示する処理を実行するとしてもよい。図３には特定の順序に従って処理を図示しているが、その他の順序で実行するとしてもよい。また、図示した処理は、並列および／または逐次的に実行するとしてよい。] 図３
[0049] 図３に示すフローのブロック３０２では、デバイスが２以上の協働デバイス（本明細書では、「協働デバイス群」とも呼ぶ）を選択する。本明細書で説明しているように、協働デバイス群は、ソースデバイスからの最初の送信の受信を確認した１以上のデバイスを含むとしてよい。また、この協働デバイス群は、ソースデバイスを含むとしてもよい。] 図３
[0050] このような構成に代えて、または、このような構成に加えて、ブロック３０２は、さまざまな選択基準に基づいて複数の協働デバイスを選択することを含むとしてよい。そのような選択基準の例を挙げると、（これらに限定されるわけではないが）ネットワークトポロジー、地形特性、チャネル特性、および／または、デスティネーション移動度レベル等があり得る。]
[0051] ブロック３０４において、選択された協働デバイス群による再送について特性を決定する。この再送は、ソースデバイスによる最初の送信（例えば、最初のデータバースト送信）の再送である。決定される特性には、リソース割り当てが含まれるとしてよい。このリソース割り当てには、再送用のリソースが含まれるとしてよい。また、このリソース割り当てには、協働デバイス群が実行するＡＣＫ／ＮＡＣＫメッセージング用のリソースが含まれるとしてよい。]
[0052] また、決定される特性には、１以上の送信技術が含まれるとしてよい。本明細書に記載するように、そのような送信技術には、仮想ＭＩＭＯ方式、分散型時空間コーディング方式、および／または分散型ビームフォーミング方式が含まれ得る。しかし、実施形態はこのような例に限定されるものではない。]
[0053] ブロック３０６において、デバイスは１以上の通知を送る。この通知には、ブロック３０２で行われた選択の結果が示されているとしてよい。この通知にはさらに、ブロック３０４で決定された特性が示されているとしてよい。]
[0054] この通知は、ＵＬ−ＭＡＰおよび／またはＤＬ−ＭＡＰ（以下で詳述する）等を用いてブロードキャスト送信方式で送られるとしてよい。このような構成に加えて、または、このような構成に代えて、この通知は、非ブロードキャスト型ＭＡＣメッセージ等のポイント・ツー・ポイントメッセージを用いて、送られるとしてもよい。このようなポイント・ツー・ポイントメッセージは、協働デバイス群に含まれるデバイスに宛てられるとしてよい。]
[0055] ＜ＩＩＩ．デバイスの実施例＞
図４は、本明細書に記載した技術に従って通信を実行する装置４００の例を示す図である。例えば、装置４００は、図２Ａ、図２Ｂおよび図３に示した処理を実行する装置であってよい。このように、装置４００は、ソースデバイス、デスティネーションデバイス、協働デバイス、および／または、再送技術を指定するデバイスとして動作するとしてよい。] 図２Ａ 図２Ｂ 図３ 図４
[0056] 図４は、装置４００がさまざまな要素、例えば、無線モジュール４０２および再送制御モジュール４０４等を備えている様子を示している。図４はさらに、装置４００がユーザインターフェース４０８を備えていることを示している。これらの要素は、ハードウェア、ソフトウェア、ファームウェア、または、これらの任意の組み合わせによって実現されるとしてよい。] 図４
[0057] 無線モジュール４０２は、１以上のアンテナ（例えば、アンテナ４０６）を介して無線信号のやり取りを実行するとしてよい。この無線信号は、さまざまな種類の無線ネットワークに準拠した無線信号であってよい。ネットワークの例を挙げると、ＩＥＥＥ８０２．１６のＷｉＭＡＸネットワーク／ＷｉＭＡＸ ＩＩネットワークがある。しかし、実施形態はこれらのネットワークに限定されるものではない。]
[0058] 無線モジュール４０２は、このような特徴を実現するべく、変調器、復調器、増幅器、フィルタ、および／または、アンテナ等の電子機器を有するとしてよい。さらに、通信インターフェースモジュール１０６は、１以上のプロトコル層に応じて動作するためのコンポーネントおよび／または機能を有するとしてよい。このようなプロトコル層により、パケットのカプセル化／カプセル解除、エラー訂正符号化／復号化、信号伝達、リンクプロトコル、および／または、媒体アクセスプロトコル等の特徴が実現され得る。しかし、実施形態によっては、その他のコンポーネントおよび／または機能を有するとしてよい。このような特徴は、ハードウェア、ソフトウェア、ファームウェア、または、これらの任意の組み合わせで実現されるとしてよい。]
[0059] 再送制御モジュール４０４が実行する処理には、再送を実行する処理が含まれる。例えば、図４は、再送制御モジュール４０４が協働デバイス群を選択する選択モジュール４１０を含むことを図示している。この選択は、本明細書に記載する技術に応じて実行されるとしてよい。図４はさらに、再送制御モジュール４０４が、本明細書に記載するように再送特性を決定する特性決定モジュール４１２を含むことを示している。] 図４
[0060] ユーザインターフェース４０８は、ユーザとのやり取りを円滑にする。ユーザとのやり取りには、ユーザからの情報の入力、および／または、ユーザへの情報の出力が含まれるとしてよい。したがって、ユーザインターフェース４０８は、キーボード（例えば、完全クワーティ（ＱＷＥＲＴＹ）型のキーボード）、キーパッド、ディスプレイ（例えば、タッチスクリーン）、マイク、および／または、音声スピーカ等、１以上のデバイスを有するとしてよい。しかし、実施形態はこれらの例に限定されるものではない。]
[0061] 上述したように、図４に示す構成要素は、ハードウェア、ソフトウェア、ファームウェア、または、これらの任意の組み合わせで実施されるとしてよい。このように、実施例には、格納媒体（例えば、メモリ）に格納されている命令または制御ロジック（例えば、ソフトウェア）を実行する１以上のプロセッサを含むとしてよい。しかし、実施形態はこのような実施例に限定されるものではない。] 図４
[0062] ＜ＩＶ．フレーム形式の例＞
図５は、さまざまな種類のネットワーク（例えば、ＷｉＭＡＸネットワーク、ＷｉＭＡＸ ＩＩネットワーク等のネットワーク）で採用される送信フレーム形式５００を示す図である。図５に示すように、この形式では、繰り返し発生するサブフレーム５０２ａ−ｄから成るサブフレームシーケンスを含む。これらのサブフレームは、ダウンリンク送信およびアップリンク送信について交互に用意されている。例えば、サブフレーム５０２ａは、ダウンリンクデータ送信用で、サブフレーム５０２ｂはアップリンクデータ送信用で、サブフレーム５０２ｃはダウンリンクデータ送信用で、サブフレーム５０２ｄはアップリンクデータ送信用である。後続するサブフレームについてもこのパターンが続く。] 図５
[0063] 図５にはさらに、サブフレーム５０２ａ−ｄがそれぞれ、制御送信用に割り当てられている部分５０４およびデータ送信用に割り当てられている部分５０６を含むことが示されている。制御送信およびデータ送信は、バーストとして実行されるとしてもよい。] 図５
[0064] 部分５０４内では、基地局がリソース割り当て情報を送信するとしてよい。この割り当ては、ダウンリンク通信用および／またはアップリンク通信用に行われるとしてよい。例えば、ＷｉＭＡＸ／ＷｉＭＡＸ ＩＩネットワークの場合、部分５０４は、ＤＬ−ＭＡＰリソース割り当ておよびＵＬ−ＭＡＰリソース割り当てを含むとしてよい。]
[0065] 実施形態によっては、部分５０４の送信は、部分５０６で送られるデータ送信よりも受信成功率が高くなるような送信技術および／または符号化技術を用いて行われるとしてよい。このように受信成功率が高くなると、その代わりに実行ビットレートは低くなってしまう場合がある。]
[0066] 上述したように、割り当て情報は部分５０４で送信されるとしてよい。一例として、図５は、ダウンリンク割り当て用ＤＬ−ＭＡＰおよびアップリンク割り当て用ＵＬ−ＭＡＰを含む（ダウンリンク用サブフレーム５０２ａおよび５０２ｃの）部分５０４ａおよび５０４ｃを図示している。ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰは、本明細書に記載した技術に応じた通信における特性を示すべく、さまざまな情報要素（ＩＥ）を利用するとしてよい。] 図５
[0067] 一例として、図５は、ＤＬ−ＭＡＰが、再送用の送信技術（例えば、ＭＩＭＯ、分散型時空間コーディング、分散型ビームフォーミング等）を指定していることを図示している。ＤＬ−ＭＡＰはさらに、協働デバイス群を指定しているとしてもよい。ＵＬ−ＭＡＰは、各協働デバイスおよびデスティネーションデバイスについて応答チャネル（ＡＣＫＣＨ）（例えば、複数の別々のチャネル）を示しているとしてよい。このようなＵＬ−ＭＡＰ割り当ておよびＤＬ−ＭＡＰ割り当ては、ダウンリンク通信（例えば、基地局から移動局への通信）に利用されるとしてよい。実施形態によっては、アップリンク通信についても、同様の割り当てを利用するとしてよい。] 図５
[0068] ＜Ｖ．ダウンリンク通信の例＞
以下では、ダウンリンク通信の例を説明する。具体的には、基地局（ＢＳ）、１以上の協働デバイス（中継局（ＲＳ）とも呼ぶ）、および移動局（ＭＳ）がある環境下におけるダウンリンク通信技術を説明する。当該ダウンリンク通信技術は、ＷｉＭＡＸ／ＷｉＭＡＸ ＩＩ通信の場合を例に挙げて説明するが、他の通信に応用するとしてもよい。]
[0069] ダウンリンクデータ送信が実行される前に、ＢＳはリソースを割り当てる。例えば、ＢＳは、ＭＳおよび１以上のＲＳに対してＤＬ−ＭＡＰを送信して、ダウンリンクデータバースト送信を特定するとしてよい。ＢＳはさらに、ＵＬ−ＭＡＰを送信して、ＡＣＫ／ＮＡＣＫメッセージング用のリソース割り当てを特定するとしてよい。実施形態によっては、このような割り当てが行われることによって、ＢＳはＲＳおよびＭＳのそれぞれから別々にＡＣＫ／ＮＡＣＫメッセージを受信するとしてよい。]
[0070] ＢＳはさらに、各ＲＳについてチャネル品質情報も受信するとしてよい。ＭＳは、この情報に基づいて、ＲＳとＭＳとの間のリンク強度を特定するとしてよい。ＢＳは、特定されたリンク強度に基づいて、複数のＲＳから協働デバイス群を選択する際にこの情報を利用するとしてよい。このチャネル品質情報は、ＣＱＩメッセージまたはＭＡＣメッセージとして、第２のホップでＢＳに送られてくるとしてよい。]
[0071] ＢＳでは、透過的または非透過的な中継が存在する場合にＢＳがＭＳおよびＲＳの両方にデータを送るように、スケジューリングを決定するとしてよい。例えば、実施形態によっては、協働ＲＳ群の決定および協働的送信技術の特定は、ＢＳで通常行う判断である。しかし、別の実施形態では、一部の決定（例えば、スケジューリングに関する決定）はＲＳで行われるとしてもよい。このようにして、一群の透過的な協働デバイス（例えば、ＢＳで指定されたもの）は、ＢＳが（第１のホップで）送ったダウンリンクデータバースト送信を（第２のホップで）送ることができる。]
[0072] ホップ単位方式および中継支援方式のダウンリンク通信の例を以下で説明する。]
[0073] ＜Ａ．ホップ単位方式＞
改良された協働的ホップ単位ＨＡＲＱアルゴリズムによると、１以上のＲＳは、（ＲＳはＤＬ−ＭＡＰによってこのバースト送信について把握しているので）ＢＳが送信するダウンリンクデータバーストを受信するとしてよい。ＲＳがいずれもバーストのデコードに成功しない場合（例えば、全てのＲＳがＢＳにＮＡＣＫを送り返す場合）、ＢＳはダウンリンクデータバーストを再送する。しかし、本明細書に記載するホップ単位方式では、ＲＳは、このデータバースト送信を、次のホップでＭＳに中継するとしてよい。]
[0074] より具体的には、１以上のＲＳがダウンリンクデータバーストを正しくデコードすると（そして、ＲＳが送った１以上のＡＣＫがＢＳで受信されると）、ＢＳは協働端末群を選択する。ＢＳは、ＡＣＫメッセージを送ったＲＳの中からこの協働端末群を選択するとしてよい。また、上述したように、この協働端末群はＢＳを含むとしてもよい。]
[0075] ＢＳは、この選択結果に基づいて、協働端末群に対してリソースを割り当てる。例えば、ＢＳは、特定の送信技術を用いてＭＳに対して同時に送信させるべく協働端末に対して時間−周波数リソースを提供するダウンリンク割り当てをＤＬ−ＭＡＰで送信するとしてよい。ＢＳはさらに、ＭＳのＡＣＫ／ＮＡＣＫメッセージングを実現するアップリンク割り当てを決定して、ＵＬ−ＭＡＰで送信するとしてよい。]
[0076] このような割り当てに従って、協働端末群は、データバースト送信をＭＳに送る。ＭＳの返答がＮＡＣＫであれば、ＢＳは協働端末群にデータバースト送信をＭＳに再送するよう通知する。]
[0077] 図６は、改良された協働的ホップ単位ＨＡＲＱアルゴリズムに従ったダウンリンク通信の一例を示す図である。具体的には、図６は、基地局（ＢＳ）、中継局（ＲＳ）、および移動局（ＭＳ）の間でのやり取りを図示している。] 図６
[0078] 三者間でのやり取りのステップ６０２では、ＢＳが（例えば、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰで）リソース割り当てを送信する。このリソース割り当てによって、ＢＳからＲＳへのダウンリンクデータ送信、および、ＲＳからのＡＣＫ／ＮＡＣＫメッセージングに対してリソースが提供される。]
[0079] ＢＳは、このリソース割り当てに基づき、ステップ６０４においてダウンリンクデータ送信（ＨＡＲＱバースト＃１として図示）を送る。続いてステップ６０６において、ＲＳがＢＳに対してＡＣＫメッセージを送り、ＨＡＲＱバースト＃１のデコードに成功した旨を知らせる。]
[0080] ステップ６０８において、ＢＳは（例えば、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰで）リソース割り当てを送る。このリソース割り当てによって、ダウンリンクデータ送信の再送、および、ＭＳからのＡＣＫ／ＮＡＣＫメッセージングが可能となる。このリソース割り当てに基づいて、ステップ６１０において、ＢＳおよびＲＳはＨＡＲＱバースト＃１を再送する。図６に示すように、これには、分散型Ａｌａｍｏｕｔｉ空間−時間コード（Ｓｐａｃｅ−Ｔｉｍｅ Ｃｏｄｅ：ＳＴＣ）に応じた同時送信を利用する。しかし、他の技術を利用するとしてもよい。] 図６
[0081] この後、ＭＳは、ステップ６１２においてＢＳへとＮＡＣＫを送り返して、ＨＡＲＱバースト＃１のデコードが不成功に終わった旨を通知する。このため、ステップ６１４において、ＢＳはさらに（例えば、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰで）リソース割り当てを送信する。この割り当てによって、ＢＳおよびＲＳによるＨＡＲＱバースト＃１の再送、および、ＭＳによるＡＣＫ／ＮＡＣＫメッセージングが可能となる。]
[0082] この割り当てによると、ＢＳおよびＲＳは再度、ステップ６１６においてＨＡＲＱバースト＃１を再送する。図６に示すように、これには、分散型Ａｌａｍｏｕｔｉ空間−時間コード（Ｓｐａｃｅ−Ｔｉｍｅ Ｃｏｄｅ：ＳＴＣ）に応じた同時送信を利用する。しかし、他の技術を利用するとしてもよい。] 図６
[0083] ステップ６１８において、ＭＳはＢＳに対してＡＣＫメッセージを送る。ＢＳは、これに応じて、ＨＡＲＱバースト＃１のデコードが成功したと結論付ける。]
[0084] ＜Ｂ．中継支援形式＞
改良された協働的中継支援型ＨＡＲＱアルゴリズムによると、ＢＳは、第１のホップによってＭＳに直接データバースト送信を送信する。１以上のＲＳは、（ＲＳはＤＬ−ＭＡＰに基づいてこの送信について把握しているので）ＢＳからＭＳへのデータバースト送信を監視する。ＲＳがこのように監視を行うのは、（必要であれば）次のホップによってＭＳへとこのデータバースト送信を中継する可能性があるためである。]
[0085] 上述したように、ＢＳは、ＭＳおよびＲＳのＡＣＫ／ＮＡＣＫメッセージングを別々にするべく（例えば、ＵＬ−ＭＡＰで）リソースを割り当てるとしてよい。協働デバイス群は、（１）ＢＳ−ＭＳリンクを介した送信についてＭＳからＮＡＣＫメッセージを受信した場合（つまり、ＭＳがデータバースト送信の受信に失敗した場合）、および（２）１以上のＲＳが正しくデータバースト送信をデコード出来た場合に、データを送信する。この２つの条件が満たされると、ＢＳは、ＡＣＫメッセージを送信したＲＳの中から協働端末群を選択する。ＢＳもまた、協働端末群に含まれるとしてもよい。]
[0086] この選択の結果に基づき、ＢＳは、協働端末群についてリソースを割り当てる。例えば、ＢＳは、特定の送信技術を用いてＭＳへデータバースト送信を協働端末群に同時に再送させるべく、ＤＬ−ＭＡＰを送信するとしてよい。また、ＢＳは、ＭＳのＡＣＫ／ＮＡＣＫメッセージングを可能とするアップリンク割り当てを決定して、ＵＬ−ＭＡＰで送信するとしてよい。]
[0087] この割り当てに従って、協働端末群はＭＳにデータバースト送信を送る。ＭＳの返答がＮＡＣＫであれば、ＢＳは、ＭＳにデータバースト送信を再送するように協働端末群に通知する。しかし、ＭＳもＲＳも第１のホップによるデータバースト送信のデコードに成功しない場合（つまり、ＭＳおよびＲＳがＢＳに対してＮＡＣＫを送り返した場合）、ＢＳはデータバースト送信を再送する。]
[0088] 図７は、ダウンリンク通信に採用される改良された協働的中継支援型ＨＡＲＱアルゴリズムに応じたダウンリンク通信の一例を示す図である。具体的には、図７は、基地局（ＢＳ）、中継局（ＲＳ）、および移動局（ＭＳ）の間でのやり取りを図示している。] 図７
[0089] 三者間でのやり取りのステップ７０２では、ＢＳが（例えば、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰで）リソース割り当てを送信する。このリソース割り当てによって、ＢＳからＭＳへのダウンリンクデータ送信、および、ＲＳおよびＭＳからのＡＣＫ／ＮＡＣＫメッセージングに対してリソースが提供される。]
[0090] ＢＳは、このリソース割り当てに基づき、ステップ７０４においてダウンリンクデータ送信（ＨＡＲＱバースト＃１として図示）を送る。図７に示すように、この送信は同時に、ＲＳおよびＭＳにも送られる。この後、ステップ７０６において、ＲＳはＢＳにＡＣＫメッセージを送り（ＨＡＲＱバースト＃１のデコードに成功したことを示し）、ＭＳはＢＳにＮＡＣＫメッセージを送る（ＨＡＲＱバースト＃１のデコードが不成功に終わったことを示す）。したがって、再送技術を利用する。] 図７
[0091] 具体的には、ステップ７０８において、ＢＳは（例えば、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰで）リソース割り当てを送る。このリソース割り当てによって、ダウンリンクデータ送信の再送、および、ＭＳからのＡＣＫ／ＮＡＣＫメッセージングが可能となる。このリソース割り当てに基づいて、ステップ７１０において、ＢＳおよびＲＳはＨＡＲＱバースト＃１を再送する。図７に示すように、これには、分散型Ａｌａｍｏｕｔｉ空間−時間コード（Ｓｐａｃｅ−Ｔｉｍｅ Ｃｏｄｅ：ＳＴＣ）に応じた同時送信を利用する。しかし、他の技術を利用するとしてもよい。] 図７
[0092] この後、ＭＳは、ステップ７１２においてＢＳへとＮＡＣＫを送る（ＨＡＲＱバースト＃１のデコードが不成功に終わった旨を通知する）。このため、ステップ７１４において、ＢＳはさらに（例えば、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰで）リソース割り当てを送信する。この割り当てによって、ＢＳおよびＲＳによるＨＡＲＱバースト＃１の再送、および、ＭＳによるＡＣＫ／ＮＡＣＫメッセージングが可能となる。]
[0093] この割り当てによると、ＢＳおよびＲＳは再度、ステップ７１６においてＨＡＲＱバースト＃１を再送する。図７に示すように、これには、分散型Ａｌａｍｏｕｔｉ空間−時間コード（Ｓｐａｃｅ−Ｔｉｍｅ Ｃｏｄｅ：ＳＴＣ）に応じた同時送信を利用する。しかし、他の技術を利用するとしてもよい。] 図７
[0094] ステップ７１８において、ＭＳはＢＳに対してＡＣＫメッセージを送る。ＢＳは、これに応じて、ＨＡＲＱバースト＃１のデコードが成功したと結論付ける。]
[0095] ＜ＶＩ．アップリンク通信の例＞
以下では、ＢＳ、１以上のＲＳ、およびＭＳがある環境下におけるアップリンク通信の例を説明する。当該アップリンク通信技術は、ＷｉＭＡＸ／ＷｉＭＡＸ ＩＩ通信の場合を例に挙げて説明するが、他の通信に応用するとしてもよい。]
[0096] アップリンク送信について、ＭＳおよび１以上のＲＳは、ＭＳからのアップリンクデータバースト送信について（例えば、ＵＬ−ＭＡＰで）ＢＳからリソース割り当てを受信するとしてよい。さらに、ＲＳは、ＡＣＫ／ＮＡＣＫメッセージング（つまり、ＡＣＫチャネル（ＡＣＫＣＨ））用のリソース割り当てを（例えば、ＵＬ−ＭＡＰで）ＢＳから受信するとしてよい。]
[0097] ＢＳでは、透過的または非透過的な中継が存在する場合にＭＳがＢＳおよびＲＳの両方にデータを送るように、スケジューリングを決定するとしてよい。透過的な協働デバイス群（例えば、ＢＳが指定するＲＳ）は、ＭＳが送るアップリンクデータバースト送信を監視するとしてよい。また、ＢＳは、各ＲＳから別個にＡＣＫ／ＮＡＣＫ信号を受信する。さらに、ＢＳは、ＣＱＩメッセージまたはＭＡＣメッセージとして、再送段階における協働デバイスの選択に向けて、各ＲＳのチャネル品質情報を受信する。]
[0098] ＜Ａ．ホップ単位方式＞
改良された協働的ホップ単位ＨＡＲＱアルゴリズムによると、ＢＳは、１以上のＲＳについてＡＣＫチャネルを割り当てる。これは、第１のホップでＭＳが送るアップリンク送信のデコードの結果についてＢＳに通知するためである。１以上のＲＳがＭＳから送られたアップリンクバースト送信のデコードに成功すれば（ＢＳは、各ＲＳからのＡＣＫ／ＮＡＣＫメッセージによって知る）、ＢＳはＭＳに対してＡＣＫメッセージを送ることによって確認を行う。]
[0099] この際、２回目のホップ送信は、第２のホップによってＢＳへこのバーストを中継するべく、協働端末群（ＲＳおよび／またはＭＳを含む）によって処理されるとしてよい。]
[0100] このため、ＢＳは、ＡＣＫメッセージを送ったＲＳの中から協働端末群を選択する。ＭＳもまた、協働端末として選択されるとしてよい。この選択に基づき、ＢＳは帯域幅（ＵＬ−ＭＡＰで通知されるとしてもよい）を協働端末群に割り当てる。このように帯域幅が割り当てられることによって、協働型中継技術を用いて、アップリンクデータバースト送信を中継（例えば、同時に中継）することが可能となるとしてよい。]
[0101] 実施形態によっては、ＢＳは協働デバイス群にＡＣＫ／ＮＡＣＫメッセージを送らない。しかし、ＢＳは、データバースト送信を正しく回復できない場合、協働端末群に対してデータバーストの再送を要求する。また、指定されたＲＳがいずれも第１のホップによってアップリンクデータバーストを正しく受信しなかった場合（例えば、ＲＳがＢＳにＮＡＣＫを送った場合）、ＢＳはデータバーストの再送のための帯域幅（ＵＬ−ＭＡＰで通知されるとしてもよい）をＭＳに割り当てる。]
[0102] 図８は、改良された協働的ホップ単位ＨＡＲＱアルゴリズムに従ったアップリンク通信の一例を示す図である。具体的には、図８は、基地局（ＢＳ）、第１の中継局（ＲＳ１）、第２の中継局（ＲＳ２）および移動局（ＭＳ）の間でのやり取りを図示している。] 図８
[0103] 三者間でのやり取りのステップ８０２では、ＢＳが（例えば、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰで）リソース割り当てを送信する。このリソース割り当てによって、ＭＳからＲＳ１およびＲＳ２へのアップリンクデータ送信、および、ＲＳ１、ＲＳ２からのＡＣＫ／ＮＡＣＫメッセージングに対してリソースが提供される。]
[0104] ＭＳは、このリソース割り当てに基づき、ステップ８０４においてアップリンクデータ送信（ＨＡＲＱバースト＃１として図示）を送る。この送信は、ＲＳ１およびＲＳ２で受信される。したがって、ステップ８０６において、ＲＳ１およびＲＳ２は共にＢＳに対してＡＣＫメッセージを送る（ＨＡＲＱバースト＃１のデコードに成功した旨を知らせる）。]
[0105] ステップ８０８において、ＢＳは（例えば、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰで）リソース割り当てを送る。このリソース割り当てによって、ＲＳ１およびＲＳ２によるアップリンクデータ送信の再送、および、ＢＳからのＡＣＫ／ＮＡＣＫメッセージングが可能となる。]
[0106] この割り当てに基づいて、ＢＳは、ステップ８１０においてＭＳにＡＣＫを送信する。このＡＣＫは、ＭＳに対して、ＲＳ１およびＲＳ２がＨＡＲＱバースト＃１のデコードに成功したことを示している。また、この割り当てに基づき、ＲＳ１およびＲＳ２は、ステップ８１２においてＨＡＲＱバースト＃１を再送する。図８に示すように、これには、分散型Ａｌａｍｏｕｔｉ空間−時間コード（Ｓｐａｃｅ−Ｔｉｍｅ Ｃｏｄｅ：ＳＴＣ）に応じた同時送信を利用する。しかし、他の技術を利用するとしてもよい。] 図８
[0107] ＜Ｂ．中継支援方式＞
改良された協働的中継支援型ＨＡＲＱアルゴリズムによると、ＢＳは、（ＡＣＫ／ＮＡＣＫメッセージングの結果に応じて）ＲＳおよび／またはＭＳがアップリンクデータバースト送信を再送すべきか否かを判断する。この場合、ＭＳがＢＳに直接送信している間、ＲＳはＵＬ−ＭＡＰの情報に基づいてこの送信を監視する。ＢＳがアップリンクデータバースト送信のデコードに失敗したが、１以上のＲＳが正しいアップリンクデータバースト送信を持っている（ＢＳは、この状況を、各ＲＳからのＡＣＫ／ＮＡＣＫメッセージによって知る）場合、ＢＳは、ＭＳに対してＡＣＫメッセージを送ることで確認を行う。このため、ＢＳへの複数の再送は、第２のホップによって協働端末群（ＲＳおよび／またはＭＳを含む）によって同時に処理されるとしてよい。]
[0108] このため、ＢＳは協働端末群を選択する。例えば、ＢＳは、ＡＣＫメッセージを送ったＲＳおよび／またはＭＳを選択するとしてよい。そして、ＢＳは、特定の送信技術を用いてアップリンクデータバースト送信を同時に中継させるべく、協働端末群に帯域幅を割り当てる（そして、ＵＬ−ＭＡＰで通知する）。]
[0109] ＢＳは、第２のホップのデータバースト送信を正しく回復できない場合、協働端末にＮＡＣＫを送るとしてよく、保存されているデータバースト送信を再送させるべく、協働デバイス群に対して帯域幅（ＵＬ−ＭＡＰで通知されるとしてよい）を割り当てる。]
[0110] 指定されたＲＳのいずれも第１のホップで送られた正しいアップリンクデータバースト送信を持っておらず（例えば、全てのＲＳがＢＳに対してＮＡＣＫを送り）、ＢＳも第１のホップで送られた正しいアップリンクデータバースト送信を回復できない場合、ＢＳはＭＳにＮＡＣＫを送るとしてよい。ＢＳはさらに、バーストを再送させるべく、ＭＳに対してリソース（ＵＬ−ＭＡＰで通知されるとしてよい）を割り当てるとしてよい。ＢＳは、ＭＳからのバーストを回復した場合には、指定されたＲＳからのＡＣＫ／ＮＡＣＫメッセージに関係なく、ＡＣＫメッセージをＭＳに送ることによって受信を確認する。]
[0111] 図９は、改良された協働的中継支援型ＨＡＲＱアルゴリズムに応じたアップリンク通信の一例を示す図である。具体的には、図９は、基地局（ＢＳ）、第１の中継局（ＲＳ１）、第２の中継局（ＲＳ２）、および移動局（ＭＳ）の間でのやり取りを図示している。] 図９
[0112] 三者間でのやり取りのステップ９０２では、ＢＳが（例えば、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰで）リソース割り当てを送信する。このリソース割り当てによって、ＭＳからＢＳ、ＲＳ１、およびＲＳ２へのアップリンクデータ送信、および、ＲＳ１およびＲＳ２からのＡＣＫ／ＮＡＣＫメッセージングに対してリソースが提供される。]
[0113] ＭＳは、このリソース割り当てに基づき、ステップ９０４においてアップリンクデータ送信（ＨＡＲＱバースト＃１として図示）を送る。ＲＳ１およびＲＳ２がこの送信を受信して、デコードに成功する。しかし、ＢＳは、この送信のデコードに失敗する。ステップ９０６において、ＲＳ１およびＲＳ２は共に、ＨＡＲＱバースト＃１のデコードに成功した旨を示すＡＣＫメッセージをＢＳに送る。]
[0114] ステップ９０８において、ＢＳは（例えば、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰで）リソース割り当てを送る。このリソース割り当てによって、ＲＳ１およびＲＳ２によるアップリンクデータ送信の再送、および、ＢＳからのＡＣＫ／ＮＡＣＫメッセージングが可能となる。]
[0115] このリソース割り当てに基づいて、ステップ９１０において、ＢＳはＭＳにＡＣＫを送信する。このＡＣＫは、ＭＳに対して、ＲＳ１およびＲＳ２がＨＡＲＱバースト＃１のデコードに成功したことを示す。また、このリソース割り当てに基づいて、ステップ９１２において、ＲＳ１およびＲＳ２はＨＡＲＱバースト＃１を再送する。図９に示すように、これには、分散型Ａｌａｍｏｕｔｉ空間−時間コード（Ｓｐａｃｅ−Ｔｉｍｅ Ｃｏｄｅ：ＳＴＣ）に応じた同時送信を利用する。しかし、他の技術を利用するとしてもよい。] 図９
[0116] ＜ＶＩＩ．送信技術＞
実施形態によれば、複数の協働デバイスによる送信（例えば、同時送信）が可能となる。この際、さまざまな送信技術を利用するとしてよい。技術の例を挙げると、（これらに限定されないが）分散型時空間コーディングおよび分散型ビームフォーミングといった仮想多入力多出力（ＭＩＭＯ）方法がある。]
[0117] 送信技術は、さまざまなデバイス（例えば、基地局）によって動的に決定されるとしてよい。ＷｉＭＡＸ／ＷｉＭＡＸ ＩＩネットワークの場合、バースト単位またはサブバースト単位で決定されるとしてよい。例えば、ＢＳは、ＤＬ−ＭＡＰで協働端末の時空間送信技術（例えば、分散型時空間コーディング、信号繰り返し、および分散型ビームフォーミング等）を特定するとしてよい。このため、協働端末ＲＳは、これに応じて送信を適応させることができるようになる。さらに、ＭＳは、これに応じて受信を適応させ得る。送信技術を動的に決定する際には、協働デバイス（例えば、ＲＳ）から報告されるＡＣＫ／ＮＡＣＫを参照するとしてよい。]
[0118] 時空間送信技術が選択されるタイミングに基づいて、対応するＭＩＭＯパイロットパターンが、チャネル推定のために協働デバイスによって利用されるとしてよい。例えば、協働デバイスの数が２つの場合、分散型Ａｌａｍｏｕｔｉ時空間コーディング（ＳＴＣ）が選定されるとしてよい。また、各協働デバイスが有するアンテナが１つの場合、デスティネーションデバイス（例えば、ＭＳまたはＢＳ）が当該デスティネーションデバイスから協働デバイスまでのチャネルを推定するべく、ＡｌａｍｏｕｔｉＳＴＣを採用しているＭＩＭＯシステムであって、送信アンテナが２つで受信アンテナが１つであるＭＩＭＯシステムと同じパイロットパターンを利用することができる。また、これによって、協働再送について適応変調符号化（ＡＭＣ）方式を実現することができる。ＷｉＭＡＸ／ＷｉＭＡＸ ＩＩネットワークの場合、実行可能であれば、このような技術を利用して下位互換性を実現するとしてよい。]
[0119] ＜ＶＩＩＩ．協働デバイスの選択＞
本明細書に記載するように、デバイス（例えば、ＢＳ）は、協働デバイス群を選択するとしてよい。この選択は、動的または静的に実行されるとしてよい。動的に選択する場合、デバイスは送信毎に協働デバイス群を特定するとしてよい。ＷｉＭＡＸ／ＷｉＭＡＸ ＩＩネットワークの場合、例えばＤＬ−ＭＡＰおよび／またはＵＬ−ＭＡＰで、動的な選択の結果を通知するとしてよい。]
[0120] しかし、協働デバイス群は、静的に、より長い期間を対象として選択されるとしてもよい。この場合の選択の結果は、例えば、媒体アクセス制御（ＭＡＣ）管理メッセージを利用してＢＳによって信号伝達されるとしてよい。この場合に利用されるＭＡＣ管理メッセージの例としては、ＩＥＥＥ８０２．１６ｊ ＷｉＭＡＸ規格で規定されているＲＳ用の協働ダイバーシティ設定メッセージ（ＲＳ ＣＤＣ）がある。このため、実施形態によっては、静的に選択する場合の結果は、ＲＳリンクの瞬時チャネル品質指標（ＣＱＩ）値に応じて変化するわけではない。]
[0121] 別の実施形態では、協働デバイスを静的に選択する際に、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰを利用することも可能である。送信毎に協働デバイス群を特定する（つまり、動的に協働デバイスを選択する）代わりに、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰを利用して、複数の送信を含む期間について、協働デバイス群を特定するとしてよい。例えば、選定された協働デバイス群は、複数の送信期間にわたって変わらないとしてよい。この方法によれば、ＭＡＣ管理メッセージを利用する方法よりも、高い自由度が得られる場合がある。一方、この方法が必要とするオーバーヘッドは、（例えば、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰの情報量が低減されて）動的な方法に比べて少なくなる場合がある。]
[0122] 静的に選択された場合、協働デバイス群は送信毎に変化しないが、送信技術は送信単位で変わるとしてもよい。例えば、協働デバイス群に含まれるある１つのデバイス（例えば、１つのＲＳ）が、ソースデバイス（例えば、ＢＳまたはＭＳ）から正しく送信を受信していない場合、当該デバイスには第２のホップでデータを送信することが許可されない。しかし、ソースデバイスは、応答チャネル（ＡＣＫＣＨ）に基づき各協働デバイスでの受信状況を把握しているので、第２のホップで利用される協働デバイスの時空間送信モードを設定することができる。上述したように、送信モードは、例えばＤＬ−ＭＡＰおよび／またはＵＬ−ＭＡＰで広告されるとしてよい。]
[0123] このように、協働的時空間送信モードは、協働デバイス群のうち一部の協働デバイス（例えば、データ送信の正しいバージョンを保有している協働デバイス）からの送信のみを必要とするようにも選択され得る。実施形態によっては、協働的時空間送信モードの特定の部分または特性は（例えば、ＭＡＣメッセージを利用して）静的に確立されて、ほかの部分または特性は（例えば、ＤＬ−ＭＡＰおよび／またはＵＬ−ＭＡＰを利用して）動的に確立されるとしてもよい。]
[0124] ＜Ｘ．結論＞
本明細書では、実施形態の徹底的な理解を目的として、具体的且つ詳細な内容を数多く記載してきた。しかし、当業者におかれては、実施形態は上述の具体的且つ詳細な内容がなくとも実施できるものと理解されたい。また、公知の処理、構成要素、および回路については、実施形態をあいまいにすることを避けるべく、詳細な説明を省略した。本明細書で具体的且つ詳細に開示した構造および機能は、例に過ぎず、実施形態の範囲を必ずしも限定するものではない。]
[0125] このように、本明細書に記載したさまざまな実施形態は例として記載されたものに過ぎず、本発明を限定するものではないと理解されたい。一例を挙げると、実施形態は、ＷｉＭＡＸまたはＷｉＭＡＸ ＩＩを利用する実施例に限定されない。]
[0126] さまざまな実施形態は、ハードウェア素子、ソフトウェア素子、または、これらの組み合わせを利用して実現されるとしてよい。ハードウェア素子の例には、プロセッサ、マイクロプロセッサ、回路、回路素子（例えば、トランジスタ、抵抗、キャパシタ、インダクタ等）、集積回路、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）、デジタルシグナルプロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ロジックゲート、レジスタ、半導体デバイス、チップ、マイクロチップ、チップセット等が含まれるとしてよい。ソフトウェアの例には、ソフトウェアコンポーネント、プログラム、アプリケーション、コンピュータプログラム、アプリケーションプログラム、システムプログラム、機械プログラム、オペレーティングシステムソフトウェア、ミドルウェア、ファームウェア、ソフトウェアモジュール、ルーチン、サブルーチン、関数、方法、プロシージャ、ソフトウェアインターフェース、アプリケーションプログラムインターフェース（ＡＰＩ）、命令群、演算コード、コンピュータコード、コードセグメント、コンピュータコードセグメント、ワード、値、シンボル、または、これらの任意の組み合わせが含まれるとしてよい。実施形態をハードウェア素子および／またはソフトウェア素子を用いて実現するか否かの判断は、さまざまな要因に基づいて為され得る。そのような要因としては、所望の演算レート、電力レベル、耐熱性、処理サイクル割り当て量、入力データレート、出力データレート、メモリリソース、データバス速度、および、その他の設計上または性能上の制約が挙げられる。]
[0127] 一部の実施形態の説明では、「結合」および「接続」という表現が見られることがある。この２つの用語は、互いに同義語として使用されているものではない。例えば、一部の実施形態の説明において「接続」および／または「結合」という用語を使用する場合、２以上の素子が直接物理的または電気的に接触している状態を意味する。しかし、「結合」という用語は、２以上の素子は、互いに直接接触していないものの、互いに協働または相互作用することを意味するとしてもよい。]
[0128] 一部の実施形態は、例えば、命令または命令群を格納している機械可読媒体または機械可読物品を用いて実現するとしてもよい。当該命令または命令群を機械で実行させることによって、実施形態に係る方法および／または処理を当該機械に実行させ得る。このような機械は、例えば、任意の適切な処理プラットフォーム、演算プラットフォーム、演算デバイス、処理デバイス、演算システム、処理システム、コンピュータ、プロセッサ等であって、ハードウェアおよび／またはソフトウェアを任意の方法で適切に組み合わせることによって実現するとしてよい。機械可読媒体または機械可読物品としては、例えば、任意の適切な種類のメモリユニット、メモリデバイス、メモリ物品、メモリ媒体、格納デバイス、格納物品、格納媒体、および／または、格納ユニットが挙げられ、例えば、メモリ、取り外し可能または取り外し不可能な媒体、消去可能または消去不可能な媒体、書き込み可能または書き換え可能な媒体、デジタル媒体またはアナログ媒体、ハードディスク、フロッピー（登録商標）ディスク、コンパクトディスク（登録商標）リードオンリーメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク（登録商標）リコーダブル（ＣＤ−Ｒ）、コンパクトディスク（登録商標）リライタブル（ＣＤ−ＲＷ）、光ディスク、磁気媒体、光磁気媒体、取り外し可能なメモリカードまたはメモリディスク、さまざまな種類のＤＶＤ、テープ、カセット等を含むとしてよい。命令は、任意の適切な高級プログラミング言語、低級プログラミング言語、オブジェクト指向型プログラミング言語、ビジュアルプログラミング言語、コンパイル型プログラミング言語、および／または、インタプリタ型プログラミング言語を用いて実装される、任意の適切な種類のコード、例えば、ソースコード、コンパイル型コード、インタプリタ型コード、実行コード、静的コード、動的コード、暗号化コード等を含むとしてよい。]
[0129] 主題を構造の特徴および／または方法の動作に固有の用語を用いて記載してきたが、本願特許請求の範囲で定義される主題は必ずしも上述した具体的な特徴または処理に限定されるものではない。上述した具体的な特徴および処理はむしろ、本願特許請求の範囲の実施例として記載したものである。]

权利要求:

請求項1
２以上の協働デバイスを含む協働デバイス群を選択する段階と、２以上の再送について１以上の特性を決定する段階とを備え、前記２以上の再送はそれぞれ、前記２以上の協働デバイスのうち対応する１つの協働デバイスから送信され、且つ、ソースデバイスから送られる最初の送信の再送である方法。
請求項2
前記２以上の協働デバイスは、前記ソースデバイスから送られる前記最初の送信を受信したことを確認した１以上の協働デバイスを含む請求項１に記載の方法。
請求項3
前記協働デバイス群および複数の異なる再送についての再送特性を修正する段階を備える請求項１に記載の方法。
請求項4
前記１以上の特性を決定する段階は、前記２以上の再送に対して１以上のリソースを割り当てる段階を有する請求項１に記載の方法。
請求項5
前記１以上の特性を決定する段階は、前記２以上の再送について分散型時空間コーディング技術を選択する段階を有する請求項１に記載の方法。
請求項6
前記１以上の特性を決定する段階は、前記２以上の再送について分散型ビームフォーミング技術を選択する段階を有する請求項１に記載の方法。
請求項7
サブフレームの一部分において前記２以上の協働デバイスに対して前記１以上の特性を送る段階をさらに備える請求項１に記載の方法。
請求項8
２以上の協働デバイスを選択する選択モジュールと、それぞれが前記２以上の協働デバイスのうち対応する１つの協働デバイスから送られる２以上の再送について１以上の特性を決定する決定モジュールとを備え、前記２以上の再送はそれぞれ、ソースデバイスから送られる最初の送信の再送である装置。
請求項9
前記２以上の協働デバイスに対して、選択された旨を示す通知を送る送受信器をさらに備える請求項８に記載の装置。
請求項10
前記送受信器は、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰのうち少なくとも１つで、および／または、ＭＡＣ管理メッセージを利用して、前記通知を送る請求項９に記載の装置。
請求項11
前記送受信器は、前記１以上の特性を示す通知を、前記２以上の協働デバイスに対して送る請求項９に記載の装置。
請求項12
前記送受信器は、ＤＬ−ＭＡＰおよびＵＬ−ＭＡＰのうち少なくとも１つで、および／または、ＭＡＣ管理メッセージを利用して、前記通知を送る請求項１１に記載の装置。
請求項13
前記最初の送信および前記２以上の再送のそれぞれは、アップリンクデータバースト送信である請求項８に記載の装置。
請求項14
前記最初の送信および前記２以上の再送のそれぞれは、ダウンリンクデータバースト送信である請求項８に記載の装置。
請求項15
前記２以上の再送では、分散型時空間コーディング送信技術を利用している請求項８に記載の装置。
請求項16
前記２以上の再送では、分散型ビームフォーミング技術を利用している請求項８に記載の装置。
請求項17
前記選択モジュールは、前記２以上の協働デバイスを変更し、前記決定モジュールは、複数の異なる再送にわたって前記１以上の特性を変更する請求項８に記載の装置。
請求項18
最初の送信を送るソースデバイスと、それぞれが前記最初の送信を受信すると、前記最初の送信の再送を同時にデスティネーションデバイスに送る２以上の協働デバイスとを備えるシステム。
請求項19
前記ソースデバイスまたは前記デスティネーションデバイスは、前記２以上の協働デバイスを選択して、前記再送のそれぞれについて１以上の特性を決定する請求項１８に記載のシステム。
請求項20
前記２以上の協働デバイスには、前記ソースデバイスが含まれており、前記ソースデバイスは、前記２以上の協働デバイスが前記最初の送信の受信を確認しない場合、前記最初の送信を再送する請求項１８に記載のシステム。